FIG. 1 gives a schematic system view of a portal server implementing such prior art web portal.
A prior art portal as, for example, represented by IBM WebSphere Portal, is built by a complex functionality implemented on a network server—for example a web server 100, the most important elements of which are logic components for user authentication 105, state handling 110, aggregation 170 of fragments, a plurality of portlets 120—further described herein—provided in respective pages 125 with a respective plurality of APIs 130 to a respective portlet container software 135 for setting them into the common web page context, and some portal storage resources 140. The logic components are operatively connected such that data can be exchanged between single components as required. This is roughly depicted in FIG. 1.
The portal realizes a request/response communication pattern, i.e., it waits for client requests and responds to these requests. A client request message includes a URL/URI which addresses the requested portal page.
In more detail, a portal engine of the web server in FIG. 1 implements an aggregation of portlets 120 based on the underlying portal content model 150 comprising a hierarchy of portal pages that may include portlets and portal information such as security settings, user roles, customization settings, and device capabilities. Within the rendered page, the portal automatically generates the appropriate set of navigation elements based on the portal model. The portal engine invokes portlets during the aggregation as required and when required and uses caching to reduce the number of requests made to portlets. The prior art IBM WebSphere Portal employs open standards such as the Java portlet API (Application Programming Interface). It also supports the use of a remote portlet via the WSRP standard.
The portlet container 135 is a single control component competent for all portlets 120, which may control the execution of code residing in each of these portlets. It provides the runtime environment for the portlets and facilities for event handling, inter-portlet messaging, and access to portlet instance and configuration data, among others.
The portal resources 140 are, in particular, the portlets 120 themselves and the pages 125, on which they are aggregated in form of an aggregation of fragments and the navigation model. A portal database 128 stores the portlet description, wherein the detail of the portlet description includes some attributes like portlet name, portlet description, portlet title, portlet short title, and keywords. The portal database also stores the content model 150, which defines the portal content structure, i.e., the structure of pages and comprises page definitions. A page definition describes a portal page and references the components (e.g., portlets) that are contained in this page. This data is stored in the database 128 in an adequate representation based on prior art techniques like relational tables.
Some prior art portals contain a navigation component which provides the possibility to nest elements and to create a navigation hierarchy, which is stored in the portal model. An activity in the rendering and aggregation processes is the generation of URLs that address portal resources, e.g., pages. A URL is generated by the aggregation logic and includes coded state information.
The aggregation state as well as the portlet state is managed by the portal. Aggregation state can include information like the current selection including the path to the selected page in the portal model, the portlets modes and states, the portlet render and action parameters, etc.
By including the aggregation state in a URL, the portal ensures that it is later able to establish the navigation and presentation context when the client sends a request for this URL.
A portlet can request the creation of a URL through the portlet API and provide parameters, i.e., said portlet render and action parameters to be included in the URL.
The portlet container 135 is a single control component competent for all portlets 120, which may control the execution of code residing in each of these portlets. It provides the runtime environment for the portlets and facilities for event handling, inter-portlet messaging, and access to portlet instance and configuration data, among others. The portal resources 140 are in particular the portlets themselves and the pages on which they are aggregated in form of an aggregation of fragments.
The user repository 129 contains user information and authentication information for each portal user. The user repository may be implemented in a database or a prior art LDAP directory. The user repository supports various retrieval operations to query information about one user, multiple users or all portal users.
Next, and with special focus to the present invention, prior art content model modifications are described which includes a graphical user interface component 160 that provides for manually controlling the layout of the plurality of rendered pages. By that interface 160 a portal administrator or a user is enabled to control the visual appearance of the web pages, for example by creating new pages, or by adding or removing portlets on pages. In particular, the administrator or user can decide which portlet is rendered at which location next to which other portlet at a given web page. The manual layout interface 160 invokes a model management component 161 which comprises the functionality for performing persistent content model modifications and offers an API for invoking this functionality.
Some prior art portals support the concept of so-called “page derivation”. This prior art concept allows for a stepwise specialization of a page. In the first step, administrator A creates a page P, defines a base layout, and adds content, i.e., portlets, to the page. After that, the administrator grants appropriate rights to other administrators or users, who themselves can modify the page and edit the layout and content of a page, thus creating a page P′ that is derived from page P and is specialized to the needs of one or multiple users. Page derivation is a prior art concept which allows to derive multiple pages from an original page, each page being adapted specifically for a user or a group of users. The portal manages the derivation hierarchy and ensures that the user obtains the correct derived page out of the hierarchy of derived pages.
When an administrator or a user modifies the page, model management 161 creates a derivation of the page and stores it into the portal database. It also stores an association between the implicit derivation and the user that performed the page modification.
For example, administrator A creates a page X that comprises portlet A, administrator B adds portlet B to page X, which results in the creation of the derived page X′, and user C is authorized to view the page X (and thus X′). In this case, when issuing a request for page X, administrator A will see portlet A (corresponding to page X), administrator B will see portlet A and B (corresponding to page X′) and user C will also see portlets A and B (corresponding to page X′). Aggregation 170 automatically selects the according page during request processing based on aggregation state and the ID of the user issuing the request.
Now user C is assumed to modify the page to include portlet C. The portal thus creates a new derived page X″ and stores this into the database 128. The derived page is associated with user X.
When invoking a request for page X now, administrator A will see portlet A, administrator B will see portlet A and B (corresponding to page X′) and user C will see portlets A, B and C (corresponding to page X″).
FIG. 2 depicts prior art interactions in a portal during the render request processing. A client 22 is depicted left, depicting the display of the portlet markup A, B, and C of respective portlets in the client browser. The portal container 135 in the central portion and the diverse portlets 120 (A, B, C) are depicted right. The communication is based on requests which are expressed in the depicted arrows.
In particular, the client issues a render request 26, e.g., for a new page, by clicking on a link displayed in its browser window. The link contains a URL and in reaction to the user action the client issues a render request 26 containing the URL. To render this new page, the portal—after receiving the render request 26—invokes state handling passing said URL; state handling then determines the aggregation state and the portlet state that is encoded in the URL or is associated with the URL. Typically, the aggregation state contains an identification of the requested page. Aggregation checks if a derived page exists for this user. Aggregation loads the according page definition from the portal database and determines the portlets that are referenced in this page definition, i.e., that are contained on the page. It sends an own render request 27 to each portlet through the portlet container 135.
In prior art, each portlet A, B and C creates its own markup independently and returns the markup fragment with the respective request response 28. The portal aggregates the markup fragments and returns the new page 22′ to the client in a respective response 29.
In prior art modifications to the content model must be performed manually, either by the user himself or by the administrator of the portal.
Although the content structure given in FIG. 2 is held deliberately simple, a person skilled in the art will appreciate that the task of configuring the pages of a portal is no more trivial, when the number of portlets and the number of pages increases.
A typical larger enterprise's portal, however, contains large numbers, e.g., thousands of pages and portlets. Due to the complexity of an enterprise portal, manual administration is inefficient as it is time-consuming, error-prone and thus expensive. In addition, in a complex portal it is not possible for a human administrator to capture the personal requirements and personal desires of all users; thus an administrator will very often not be able to arrange all pages and portlets properly, such that a user visiting the portal may easily find his way.
An improper configuration of portal pages results in a user-unfriendly content structure and in difficult navigation. This may disadvantageously degrade the usability of the portal and a user's productivity, as the user is not able to access required content or required portlets or has to perform too many switches between pages in order to work with the portal.
Accordingly, there is an opportunity for additional helpdesk support and user training in such a complex content structure.